Summary

Two changes that make the Flashduty CLI work cleanly under the runner's bash tool:

1. Auth via bash extraEnv (drops the dedicated flashduty_exec wire op).
2. Hermetic CLI via PATH precedence — the runner's own bundled flashduty always wins over any copy the BYOC host happens to have on PATH.

Paired with fc-safari PR #74 (the bash guard that injects auth and rejects credential read-back).

1. Auth via bash extraEnv (supersedes flashduty_exec)

Safari recognizes flashduty CLI invocations in bash commands, injects FLASHDUTY_APP_KEY into the bash payload's env map for that one subprocess, and the runner just honors env like it already does for bash. This supersedes the earlier Phase 2 design (dedicated runner op + dedicated safari tool) — see fc-safari PR #74 for the rationale.

Removed:

• protocol.TaskOpFlashdutyExec + FlashdutyExecArgs (wire op no longer needed)
• case TaskOpFlashdutyExec: dispatch in ws/handler.go
• Environment.FlashdutyExec() public + executeFlashdutyExec() impl
• Two unit tests covering the deleted argv-isolated path

Kept (with tightened comments):

• scrubFlashdutySecrets on executeBashCommand — defense-in-depth so the runner's own ambient FLASHDUTY_* never leaks into a bash subprocess on BYOC dev workstations where the operator's shell exports them. Safari's per-call extraEnv overlay still wins the merge for genuine CLI invocations because extraEnv is layered last.
• All output capture / 10MB cap / .outputs/ spill semantics unchanged.

Added:

• TestEnvironment_Bash_ExtraEnvFlashdutyInjection pins the overlay-wins-scrub contract end-to-end on the bash path.

Wire shape

Safari sends a normal bash payload; the new bit is the optional env:

{
  "command": "flashduty incident list --severity Critical --progress Triggered,Processing --output-format toon",
  "workdir": "...",
  "timeout": 120,
  "env": { "FLASHDUTY_APP_KEY": "..." }
}

The runner merges env on top of scrubFlashdutySecrets(os.Environ()) and hands the result to exec.CommandContext. The credential lives in exactly one process's envp and dies with it.

2. Hermetic CLI: bundled-tools PATH precedence (commit 6c898876)

Problem (Q2 from the design discussion): on a BYOC host the customer may already have their own flashduty on PATH (different version, different auth). If the bash subprocess resolves flashduty to the host copy, Safari's injected FLASHDUTY_APP_KEY would be handed to a binary we don't control, and version drift could break flag parsing.

Fix: executeBashCommand now prepends the runner's bundled-tools directory to the subprocess PATH, so our flashduty shadows any host copy:

• bundledToolsDir() — FLASHDUTY_RUNNER_BIN_DIR env override if set, else filepath.Dir(os.Executable()) (the directory the runner binary itself lives in, where the CLI is bundled alongside it).
• withBundledToolsPath(env, dir) — folds the dir onto the front of the existing PATH= entry. Idempotent: no-op when the dir is already first; handles empty PATH, empty dir, and a missing PATH entry.

Added: environment/bundled_tools_path_test.go — table test covering prepend / already-first / absent / empty-value / empty-dir / not-first.

This is independent of the auth overlay: PATH resolution picks which binary runs; extraEnv supplies its credential.

Trade-off vs the dedicated tool

Argv isolation is gone — flashduty <verb> now runs inside bash -c "..." so a malicious model could theoretically pipe stdout through xxd or similar. Safari's bash guard (PR #74) rejects the obvious leak paths:

• Any command referencing FLASHDUTY_APP_KEY / FLASHDUTY_API_KEY by name
• Bulk env dumps (env, printenv, compgen -e, /proc/*/environ)

Residual risk is accepted for BYOC/sandbox where the runner already runs under customer-owned credentials in a customer-controlled environment.

Test plan

• go test ./... -count=1 — all green (envd / environment / permission, incl. the new PATH-precedence table)
• go build ./... && go vet ./... clean
• CI: all jobs green
• E2E via paired safari PR — see PR #74 for the captured SSE transcripts